package com.zjl.redis.第11章_redis多线程;

/**
 * redis到底是单线程还是多线程?
 *
 *
 *   redis4之后才慢慢支持多线程，但是开始仅仅加了点多线程的东西(异步删除)，持久化命令等
 *   直到redis6/7后才稳定。是应为多线程又加了 对网络请求是用多线程控制的
 *         另外,多线程IO默认也是不开启的,需要再配置文件中配置:redis.conf
 *         io-threads-do-reads yes//yes:是开启多线程IO    no：关闭
 *         io-threads 4//支持多线程的线程数最好要小于cpu的核数
 *
 *   Redis命令工作线程是单线程的，但Redis的其他功能，
 *        比如持久化RDB、AOF、异步删除、集群数据同步等等，其实是由额外的线程执行的。
 *        Redis俞令工作线程是单线程的，但是，整个Redis来说，是多线程的;
 *
 *
 *  简单来说，Redis4.0之前一直采用单线程的主要原因有以下三个:
 *      1.使用单线程模型是Redis的开发和维护更简单，因为单线程模型方便开发和调试;
 *      2.即使使用单线程模型也并发的处理多客户端的请求，主要使用的是IO多路复用和非阻塞IO;
 *      3.对于Redis系统来说，主要的性能瓶颈是内存或者网络带宽而并非CPU。
 *      4.单线程的原因是因为多线程需要大量的保证线程的 key、lua、事务，LPUSH/LPOP等等的并发问题。
 *          之所以这么设计是不想因为多线程而变得复杂。
 *
 * *********************************单线程的缺点*********************************
 *          正常情况下使用del指令可以很快的删除数据，而当被删除的key是一个非常大的对象时，
 *          例如时包含了成千上万个元素的hash集合时，那么del指令就会造成Redis主线程卡顿。
 *
 *          这就是redis3.x单线程时代最经典的故障，大key删除的头疼问题，
 *
 *          由于redis是单线程的，del bigKey ....
 *          等待很久这个线程才会释放，类似加了一个 slynchronized 锁， 你可以想象高并发下，程序堵成什么样子?
 * *********************************单线程的缺点解决*********************************
 *          使用惰性删除可以有效的避免 Redis 卡顿的问题
 *
 *           在Redis 4.0就引入了多个线程来实现数据的异步惰性删除等功能,
 *           但是其处理读写请求的仍然只有一个线程，所以仍然算是狭义上的单线程。
 *           unlink key  #惰性删除指定key
 *           Flushdb sync//同步清空当前库
 *           Flushdb async//异步清空当前库，先惰性删除，背后别的线程慢慢删
 *
 *          因为Redis是单个主线程处理，redis之父 antirez 一直 强调"Lazy Redis is better Redis" 懒惰的redis才是好的redis.
 *          而 lazy free 的本质就是把某些cost(主要时间复制度，占用主线程cpu时间片)较高删除操作，
 *          从redis主线程剥离让bio子线程来处理，极大地减少主线阻塞时间，从而减少删除导致性能和稳定性问题。
 *
 *
 *
 *
 *
 *
 * IO多路复用听说过吗?
 * redis为什么快?
 *
 */
public class A_redis单线程和多线程 {
}
